-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix decorator not being applied to transient dependencies #941
Conversation
There is a bug that only manifests when decorating objects in Fx where transient dependency types are not properly decorated. For example, if type A depends on type B, and type B depends on type C which has a decorator, it fails to recognize that. This only occurs when all constructors and the decorators for all these types are provided at the "root" level fx.App. This happens because fx injects a fake "root" Scope between the actual root Container (which is where constructors are provided to by default). Fixed by making fx stop create this fake root Scope and use the dig.Container directly. Fixes uber-go#940.
Codecov Report
@@ Coverage Diff @@
## master #941 +/- ##
=======================================
Coverage 98.72% 98.72%
=======================================
Files 30 30
Lines 1337 1337
=======================================
Hits 1320 1320
Misses 11 11
Partials 6 6
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
// TODO: Once fx.Decorate is in-place, | ||
// use the root container instead of subscope. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
heh
Thank, could you publish a release? |
@zenthangplus Sure, I can. But can you wait until Monday, please? I'll need to verify the new version with Uber's Go Monorepo and we don't do releases on Friday to avoid causing issues over the weekend for services. |
@sywhang i've tested, fx.Decorate work well, but seems fx.Replace is not work as expected. As i known, Replace is equivalent with Decorate. |
Can you be more specific? What's the code you wrote to test it? |
Oops, seems have some problem on master branch. When upgrading to latest code on master branch, my app is not run correctly, i don't know why, but i'm investigating. I'm using the bellow function to handle request (for testing only).
But when run a test suite with two test cases, the last test case seems not run correctly. OnStart hook seems only run once time. Then i've tried to revert to v1.18.1 and it works correctly. Seems latest code on master has problem. |
Thanks for catching that @zenthangplus. |
Hey @zenthangplus, could you please specify what you mean? OnStart/OnStop hooks are only supposed to run once. If you were relying on it being run twice, that's not the intended behavior. |
@sywhang In my case, i've wrote test for integration api testing. every http call to my api will be handled by this function.
Before it works well, but after this MR #931 (again, it not related to this MR) |
@zenthangplus I've created #945. Let's continue the discussion there. |
type PriceService struct { | ||
DefaultPrice int | ||
} | ||
app := fxtest.New(t, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test would pass even if none of the functions executed. What guarantees the assertions on 337 and 344 are called?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Invokes are guaranteed to run (and the fact that it ran is guaranteed by fx.RequireStart().RequireStop()
- if any Invokes fail to run, that fails the test). Invoke running successfully means assertion in line 344 are called.
And yes, line 337 in itself does not guarantee the execution, but the assertion in line 344 means both constructors Provide
d here ran successfully.
There is a bug that only manifests when decorating objects in Fx where transient dependency types are not properly decorated. For example, if type A depends on type B, and type B depends on type C which has a decorator, it fails to recognize that. This only occurs when all constructors and the decorators for all these types are provided at the "root" level fx.App. This happens because fx injects a fake "root" Scope between the actual root Container (which is where constructors are provided to by default). Fixed by making fx stop create this fake root Scope and use the dig.Container directly. Fixes uber-go#940.
There is a bug that only manifests when decorating objects in Fx where transient dependency types are not properly decorated. For example, if type A depends on type B, and type B depends on type C which has a decorator, it fails to recognize that.
This only occurs when all constructors and the decorators for all these types are provided at the "root" level fx.App.
This happens because fx injects a fake "root" Scope between the actual root Container (which is where constructors are provided to by default).
Fixed by making fx stop create this fake root Scope and use the dig.Container directly.
Fixes #940.